Conversation
![ellipsis-dev[bot]](https://avatars.githubusercontent.com/in/64358?s=60&v=4){kind=small}
There was a problem hiding this comment.
Important
Looks good to me! 👍
Reviewed everything up to 516145f in 3 minutes and 30 seconds. Click for details.
- Reviewed
26lines of code in2files - Skipped
0files when reviewing. - Skipped posting
2draft comments. View those below. - Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.
1. .github/workflows/ci.yml:35
- Draft comment:
Updated to v21, but note that this release has dropped support for x86_64-darwin. Your CI matrix (lines 23-26) includes a macOS runner using x86_64-darwin. Please verify whether you intend to continue testing on this platform or adjust the matrix accordingly. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% This comment has several issues: 1) It asks the PR author to "verify" something, which violates the rule about not asking authors to confirm intentions or double-check things. 2) The comment is speculative - it assumes that v21 dropping x86_64-darwin support will cause an issue, but if this would actually break the CI, it would be caught when the workflow runs. 3) I don't have strong evidence that v21 actually dropped x86_64-darwin support - this is an external claim about a dependency change. 4) The rules explicitly state "Do NOT comment on dependency changes, library versions that you don't recognize, or anything else related to dependencies." This is fundamentally a dependency version upgrade comment. Could the comment be valid if v21 truly dropped x86_64-darwin support and this would cause a silent failure rather than an obvious build break? Perhaps the CI would pass but not actually test what it's supposed to test. Even if there's a potential issue, the comment explicitly asks the author to "verify" which violates the rules. Additionally, if the nix-installer-action doesn't support x86_64-darwin, the CI job would likely fail obviously when it tries to install Nix on the macos-13 runner, which would be caught by the build. The rules say not to comment on things that would be obviously caught by the build. This comment should be deleted because: 1) It asks the PR author to "verify" something, which violates the rules, 2) It's about a dependency version change, which the rules say not to comment on, 3) Any actual incompatibility would be caught when the CI runs, and 4) There's no strong evidence visible in the diff that this is definitely a problem.
2. .github/workflows/devcontainer.yml:37
- Draft comment:
This update uses a commit hash to reference v21. Consider whether to use the release tag (e.g. @v21) if available for clarity, unless you intentionally prefer a pinned commit hash for security. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% The comment is asking the author to "consider whether" to use a different format, which is essentially asking them to confirm their intention or make a judgment call. The PR author clearly updated from v19 to v21 using the same commit hash pattern that's consistently used throughout the entire workflow file for all actions. This is a deliberate and consistent pattern in the codebase. The comment is speculative ("unless you intentionally prefer...") and doesn't point to a clear code issue. It's more of a style suggestion that questions the author's choice without strong evidence that it's wrong. According to the rules, comments that ask the author to confirm their intention or are speculative should be deleted. The comment could be seen as a valid code quality suggestion about using more readable version tags. Using commit hashes is a security best practice in GitHub Actions to prevent tag manipulation attacks, so the current approach might actually be the better choice. While it could be a code quality suggestion, the comment is phrased as asking the author to "consider whether" to change it, which is asking them to confirm their intention. More importantly, the entire file consistently uses commit hashes for all actions, showing this is an intentional pattern. The comment doesn't provide strong evidence that this is wrong - in fact, pinning to commit hashes is a security best practice. This makes the comment speculative and not actionable. This comment should be deleted. It asks the author to consider/confirm their intention rather than pointing to a clear code issue. The use of commit hashes is consistent throughout the file and is actually a security best practice for GitHub Actions. The comment is speculative and not actionable.
Workflow ID: wflow_qwlvRWPVkxkoeE43
You can customize 
renovate
bot
force-pushed
the
renovate/determinatesystems-nix-installer-action-21.x
branch
from
516145f to
2a0021d
Compare
renovate
bot
force-pushed
the
renovate/determinatesystems-nix-installer-action-21.x
branch
from
2a0021d to
d8947f7
Compare
|
Important Review skippedBot user detected. To trigger a single review, invoke the You can disable this status message by setting the
Comment |
renovate
bot
force-pushed
the
renovate/determinatesystems-nix-installer-action-21.x
branch
from
d8947f7 to
d270dd8
Compare
kasuboski
deleted the
renovate/determinatesystems-nix-installer-action-21.x
branch
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
v19→v21Release Notes
DeterminateSystems/nix-installer-action (DeterminateSystems/nix-installer-action)
v21Compare Source
What's Changed
Update to determinate by default by @grahamc in #208
If determinate is false, pass --prefer-upstream by @grahamc in #202
Drop x86_64-darwin by @grahamc in #207
Update
detsys-ts: Merge pull request #109 from DeterminateSystems/tsup-to-tsdown by @detsys-pr-bot in #203Update
detsys-ts: Merge pull request #114 from DeterminateSystems/dependabot/npm_and_yarn/npm-deps-47c548f420 by @detsys-pr-bot in #206Full Changelog: DeterminateSystems/nix-installer-action@v20...v21
v20Compare Source
What's Changed
detsys-ts: Merge pull request #106 from DeterminateSystems/fix-dependabot-warning by @detsys-pr-bot in #194detsys-ts: Capture the version of Nix in addition to the nix store version (#108) by @detsys-pr-bot in #197Full Changelog: DeterminateSystems/nix-installer-action@v19...v20
Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.